Configuring SRDs

The SRDs table lets you configure up to 600 (SE), 20 (VE/CE 32-64 GB), 70 (VE/CE 3.5 GB), 100 (VE/CE 4 GB), 200 (VE/CE 8 GB), 400 (VE/CE 16 GB), and 600 (VE/CE 32-64 GB) signaling routing domains (SRD). The SRD is a logical representation of an entire SIP-based VoIP network (Layer 5) consisting of groups of SIP users and servers. The SRD is associated with all the configuration entities (e.g., SIP Interfaces and IP Groups) required for routing calls within the network. Typically, only a single SRD is required (recommended) for most deployments. Multiple SRDs are only required for multi-tenant deployments, where the physical device is "split" into multiple logical devices. For more information on multi-tenant architecture, see Multiple SRDs for Multi-tenant Deployments.

As the device is shipped with a default SRD ("DefaultSRD" at Index 0), if your deployment requires only one SRD, you can use the default SRD instead of creating a new one. When only one SRD is employed and you create other related configuration entities (e.g., SIP Interfaces), the default SRD is automatically assigned to the new configuration entity. Therefore, when employing a single-SRD configuration topology, there is no need to handle SRD configuration (i.e., transparent).

You can assign SRDs to the following configuration entities:

■

SIP Interface (mandatory) - see Configuring SIP Interfaces

■

IP Group (mandatory) - see Configuring IP Groups

■

Proxy Set (mandatory) - see Configuring Proxy Sets

■

(SBC application only) Classification rule - see Configuring Classification Rules

As mentioned previously, if you use only a single SRD, the device automatically assigns it to the above-listed configuration entities.

As each SIP Interface defines a different Layer-3 network (see Configuring SIP Interfaces for more information) on which to route or receive calls and as you can assign multiple SIP Interfaces to the same SRD, for most deployment scenarios (even for multiple Layer-3 network environments), you only need to employ a single SRD to represent your VoIP network (Layer 5). For example, if your VoIP deployment consists of an corporate IP PBX (LAN), a SIP Trunk (WAN), and far-end users (WAN), you would only need a single SRD. The single SRD would be assigned to three different SIP Interfaces, where each SIP Interface would represent a specific Layer-3 network (IP PBX, SIP Trunk, or far-end users) in your environment. The following figure provides an example of such a deployment:

The following procedure describes how to configure SRDs through the Web interface. You can also configure it through ini file [SRD] or CLI (configure voip > srd).

➢

To configure an SRD:

1.

Open the SRDs table (Setup menu > Signaling & Media tab > Core Entities folder > SRDs).

2.

Click New; the following dialog box appears:

3.

Configure an SRD according to the parameters described in the table below.

4.

Click Apply.

SRDs table Parameter Descriptions

Parameter	Description
General
'Index' [Index]	Defines an index for the new table row. Note: Each row must be configured with a unique index.
'Name' name [Name]	Defines a descriptive name, which is used when associating the row in other tables. The valid value can be a string of up to 40 characters. Note: ■ The parameter is mandatory. ■ Configure each row with a unique name. ■ The parameter value can't contain a forward slash (/). ■ The parameter value can't be configured with the character string "any" (upper or lower case).
'Sharing Policy' type [SharingPolicy]	Defines the sharing policy of the SRD, which determines whether the SRD shares its SIP resources (SIP Interfaces, Proxy Sets, and IP Groups) with all other SRDs (Shared and Isolated). ■ [0] Shared = (Default) SRD shares its resources with other SRDs (Isolated and Shared) and calls can thus be routed between the SRD and other SRDs. ■ [1] Isolated = SRD doesn't share its resources with other SRDs and calls cannot be routed between the SRD and other Isolated SRDs. However, calls can be routed between the SRD and other Shared SRDs. For more information on SRD Sharing Policy, see Multiple SRDs for Multi-tenant Deployments.
'SBC Operation Mode' sbc-operation-mode [SBCOperationMode]	Defines the device's operational mode for the SRD. ■ [0] B2BUA = (Default) Device operates as a back-to-back user agent (B2BUA), changing the call identifiers and headers between the inbound and outbound legs. ■ [1] Call Stateful Proxy = Device operates as a Stateful Proxy, passing the SIP message transparently between inbound and outbound legs. In other words, the same SIP dialog identifiers (tags, Call-Id and CSeq) occur on both legs (as long as no other configuration disrupts the CSeq compatibleness). For more information on B2BUA and Stateful Proxy modes, see B2BUA and Stateful Proxy Operating Modes. Note: ■ The settings of the parameter also determines the default behavior of related parameters in the IP Profiles table (SBCRemoteRepresentationMode, SBCKeepVIAHeaders, SBCKeepUserAgentHeader, SBCKeepRoutingHeaders, SBCRemoteMultipleEarlyDialogs). ■ If the 'SBC Operation Mode' parameter is configured in the IP Groups table, the 'SBC Operation Mode' parameter in the SRDs table is ignored.
'SBC Routing Policy' sbc-routing-policy-name [SBCRoutingPolicyName]	Assigns a Routing Policy to the SRD. By default, no value is defined if you have configured multiple Routing Policies. If you have configured only one Routing Policy, the device assigns it to the SRD by default. For more information on Routing Policies, see Configuring SBC Routing Policy Rules. Note: ■ If you have assigned a Routing Policy to a Classification rule that is associated with the SRD, the Routing Policy assigned to the SRD is ignored. ■ You can assign the same Routing Policy to multiple SRDs.
'Used By Routing Server' used-by-routing-server [UsedByRoutingServer]	Enables the SRD to be used by a third-party routing server or ARM for call routing decisions. ■ [0] Not Used (default) ■ [1] Used For more information on the third-party routing server or ARM feature, see Centralized Third-Party Routing Server.
'Dial Plan' sbc-dial-plan-name [SBCDialPlanName]	Assigns a Dial Plan to the SRD. The device searches the Dial Plan for a dial plan rule that matches the source number and if not found, for a rule that matches the destination number. If a matching dial plan rule is found, the rule's tag is used in the routing and/or manipulation processes as source and/or destination tags. To configure Dial Plans, see Configuring Dial Plans.
'CAC Profile' cac-profile [AdmissionProfile]	Assigns a Call Admission Control Profile (CAC rules) to the SRD. By default, no value is defined. To configure CAC Profiles, see Configuring Call Admission Control.
Registration
'Max. Number of Registered Users' max-reg-users [MaxNumOfRegUsers]	Defines the maximum number of users belonging to the SRD that can register with the device. The default is -1, which means that the number of allowed user registrations is unlimited.
'User Security Mode' block-un-reg-users [BlockUnRegUsers]	Defines the blocking (reject) policy for incoming SIP dialog-initiating requests (e.g., INVITE messages) from registered and unregistered users belonging to the SRD. ■ [0] Accept All = (Default) Accepts requests from registered and unregistered users. ■ [1] Accept Registered Users = Accepts requests only from users registered with the device. Requests from users not registered are rejected. ■ [2] Accept Registered Users from Same Source = Accepts requests only from registered users whose source address is the same as that registered with the device (during the REGISTER message process). All other requests are rejected. If the transport protocol is UDP, the verifies the IP address and port; otherwise, it verifies only the IP address. The verification is performed before any of the device's call handling processes (i.e., Classification, Manipulation and Routing). Note: ■ The parameter is applicable only to calls belonging to User-type IP Groups. ■ The feature is not applicable to REGISTER requests. ■ The option, Accept Registered Users from Same Source [2] doesn't apply to registration refreshes. These requests are accepted even if the source address is different to that registered with the device. ■ When the device rejects a call, it sends a SIP 500 "Server Internal Error" response to the user. In addition, it reports the rejection (Dialog establish failure - Classification failure) using the Intrusion Detection System (IDS) feature (see Configuring IDS Policies), by sending an SNMP trap. ■ When the corresponding parameter in the SIP Interfaces table ('User Security Mode') is configured to any value other than Not Configured for a SIP Interface that is associated with the SRD, the parameter in the SRDs table is ignored for calls belonging to the SIP Interface.
'Enable Un-Authenticated Registrations' enable-un-auth-registrs [EnableUnAuthenticatedRegistrations]	Enables the device to accept REGISTER requests and register them in its registration database from new users that have not been authenticated by a proxy/registrar server (due to proxy down) and thus, re-routed to a User-type IP Group. In normal operation scenarios in which the proxy server is available, the device forwards the REGISTER request to the proxy and if authenticated by the proxy (i.e., device receives a success response), the device adds the user to its registration database. The routing to the proxy is according to the SBC IP-to-IP Routing table where the destination is the proxy’s IP Group. However, when the proxy is unavailable (e.g., due to network connectivity loss), the device can accept REGISTER requests from new users if a matching alternative routing rule exists in the SBC IP-to-IP Routing table where the destination is the user’s User-type IP Group (i.e., call survivability scenarios) and if the parameter is enabled. ■ [0] Disable = The device rejects REGISTER requests from new users that were not authenticated by a proxy server. ■ [1] Enable = (Default) The device accepts REGISTER requests from new users even if they were not authenticated by a proxy server, and registers the user in its registration database. Note: ■ Regardless of the parameter, the device always accepts registration refreshes from users that are already registered in its database. ■ For a SIP Interface that is associated with the SRD, if the corresponding parameter in the SIP Interfaces table ('Enable Un-Authenticated Registrations') is configured to Disable or Enable, the parameter in the SRD is ignored for calls belonging to the SIP Interface.